Inside a ChromeWorker such as toolkit/components/translations/content/translations-engine.worker.js

You can create a console instance, like:

const lazy = {};

ChromeUtils.defineLazyGetter(lazy, "console", () => {
  return console.createInstance({
    maxLogLevelPref: "browser.ml.logLevel",
    prefix: "ML",
  });
});

But when it gets cycle collected, it crashes with an assertion about being on the incorrect thread.

INFO - GECKO(1052) | [1256] Assertion failure: NS_IsMainThread() (Wrong thread!), at /builds/worker/checkouts/gecko/xpcom/threads/nsThreadManager.cpp:235
INFO -  Initializing stack-fixing for the first stack frame, this may take a while...
INFO - GECKO(1052) | #01: mozilla::AssertIsOnMainThread() [xpcom/threads/nsThreadManager.cpp:235]
INFO - GECKO(1052) | #02: mozilla::dom::ConsoleInstance::~ConsoleInstance() [dom/console/ConsoleInstance.cpp:84]
INFO - GECKO(1052) | #03: mozilla::dom::ConsoleInstance::cycleCollection::DeleteCycleCollectable(void*) [dom/console/ConsoleInstance.h:17]
INFO - GECKO(1052) | #04: SnowWhiteKiller::MaybeKillObject(SnowWhiteKiller::SnowWhiteObject&) [xpcom/base/nsCycleCollector.cpp:2514]
INFO - GECKO(1052) | #05: SnowWhiteKiller::~SnowWhiteKiller() [xpcom/base/nsCycleCollector.cpp:2497]
INFO - GECKO(1052) | #06: nsCycleCollector::FreeSnowWhite(bool) [xpcom/base/nsCycleCollector.cpp:2689]
INFO - GECKO(1052) | #07: nsCycleCollector::BeginCollection(mozilla::CCReason, ccIsManual, nsICycleCollectorListener*) [xpcom/base/nsCycleCollector.cpp:3682]
INFO - GECKO(1052) | #08: nsCycleCollector::Collect(mozilla::CCReason, ccIsManual, js::SliceBudget&, nsICycleCollectorListener*, bool) [xpcom/base/nsCycleCollector.cpp:0]
INFO - GECKO(1052) | #09: nsCycleCollector_collect(mozilla::CCReason, nsICycleCollectorListener*) [xpcom/base/nsCycleCollector.cpp:4018]
INFO - GECKO(1052) | #10: mozilla::dom::workerinternals::(anonymous namespace)::WorkerJSRuntime::CustomGCCallback(JSGCStatus) [dom/workers/RuntimeService.cpp:836]
INFO - GECKO(1052) | #11: js::gc::GCRuntime::maybeCallGCCallback(JSGCStatus, JS::GCReason) [js/src/gc/GC.cpp:4240]
INFO - GECKO(1052) | #12: js::gc::GCRuntime::gcCycle(bool, js::SliceBudget const&, JS::GCReason) [js/src/gc/GC.cpp:4328]
INFO - GECKO(1052) | #13: js::gc::GCRuntime::collect(bool, js::SliceBudget const&, JS::GCReason) [js/src/gc/GC.cpp:4513]
INFO - GECKO(1052) | #14: js::gc::GCRuntime::gc(JS::GCOptions, JS::GCReason) [js/src/gc/GC.cpp:4591]
INFO - GECKO(1052) | #15: JS::NonIncrementalGC(JSContext*, JS::GCOptions, JS::GCReason) [js/src/gc/GCAPI.cpp:300]
INFO - GECKO(1052) | #16: mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunnable::Run() [dom/workers/RuntimeService.cpp:2184]
INFO - GECKO(1052) | #17: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1194]
INFO - GECKO(1052) | #18: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:480]
INFO - GECKO(1052) | #19: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:0]
INFO - GECKO(1052) | #20: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:346]
INFO - GECKO(1052) | #21: nsThread::ThreadFunc(void*) [xpcom/threads/nsThread.cpp:372]
INFO - GECKO(1052) | #22: _pt_root [nsprpub/pr/src/pthreads/ptthread.c:204]
INFO - GECKO(1052) | #23: set_alt_signal_stack_and_start(PthreadCreateParams*) [mozglue/interposers/pthread_create_interposer.cpp:81]
INFO - GECKO(1052) | #24: ??? [/lib/x86_64-linux-gnu/libpthread.so.0 + 0x76db]
INFO - GECKO(1052) | #25: clone [/lib/x86_64-linux-gnu/libc.so.6 + 0x121a3f]
INFO - GECKO(1052) | #26: ??? (???:???)

I'm not sure why we even need that assert? Seems like mMaxLogLevelPref would always be empty on workers anyway, because we check for NS_IsMainThread() before setting it.

Set release status flags based on info from the regressing bug 1876589

(In reply to Peter Van der Beken [:peterv] from comment #1)

I'm not sure why we even need that assert? Seems like mMaxLogLevelPref would always be empty on workers anyway, because we check for NS_IsMainThread() before setting it.

That's true. I'm not sure where I got that from, I'll remove it.

(In reply to Greg Tatum [:gregtatum] from comment #0)

const lazy = {};

ChromeUtils.defineLazyGetter(lazy, "console", () => {
  return console.createInstance({
    maxLogLevelPref: "browser.ml.logLevel",
    prefix: "ML",
  });
});

Note: this should be using maxLogLevel rather than maxLogLevelPref as it is inside a worker. Unfortunately the current warning is only in debug builds. I'll see if I can get that logged to the console instead, as most front-end developers won't be using debug builds.

Also raise an error on the console if 'maxLogLevelPref' is used when it shouldn't be.

Setting S3 because of MOZ_ASSERT failure. Feel free to upgrade it if you think this is more serious bug.

Backed out for causing xpcshell failures on test_worker.js

• Backout link
• Push with failures
• Failure Log 1
• Failure Log 2

I've taken a look and afaict every other xpcshell test that uses ChromeWorker is disabled on android, so I'll do the same here.

https://hg.mozilla.org/mozilla-central/rev/d6bd2848cd90